Isn't this font and terminal emulator dependent? (e.g. 🏳️‍🌈 is 1 wide in a browser but in my terminal emulator, displaying as 🏳️🌈)

I'm far from an expert on this, but isn't that lack of adherence to the standard by the terminal, not variability that should be handled?

isn't that lack of adherence to the standard by the terminal

In any case, textwidth seems to follow the behavior in the terminal. So textwidth itself, and thus these proposed functions, are really specific to terminal, or at least fixed-width usage?

I'm far from an expert on this, but isn't that lack of adherence to the standard by the terminal, not variability that should be handled?

no. Quoting https://www.unicode.org/emoji/charts/emoji-zwj-sequences.html:

The following are the recommended emoji zwj sequences, which use a U+200D ZERO WIDTH JOINER (ZWJ) to join the characters into a single glyph if available. When not available, the ZWJ characters are ignored and a fallback sequence of separate emoji is displayed. Thus an emoji zwj sequence should only be supported where the fallback sequence would also make sense to a viewer.

These are adjacent functions to rpad/lpad and it was decided to make those textwidth-based, so isn't the point moot? #38256

(It definitely depends on the terminal; see the classic issue #3721 — but alternatives like length are even worse.)

Do we really need all three of these in the stdlib? ctrunc seems especially esoteric.

I see two arguments for this functionality finding its way into Base.

• With respect to fitting a string to a certain width, it's the other half of lpad/rpad
• A naive implementation of truncation is prone to bugs, even appearing in the stdlib (see: the bugs I picked up in Profile that Ian referenced)

With regards to why ctrunc should be included at all, I'd consider centered truncation to be similarly common to ltrunc / rtrunc. For example, it's what string's 3-arg show does: "abc..." ⋯ 326 bytes ⋯ "...xyz".

While cpad is easy to implement based on lpad and rpad:

cpad(str, w) = lpad(rpad(str, w ÷ 2), w)

and this was given as the reason why cpad was depreciated in 2017 (#23187).

Unlike cpad, ctrunc is not trivially formed from a combination of ltrunc and rtrunc, and shares all of the same risks with naive implementations. On this basis, I see it as a worthwhile inclusion.

Oh also, I've just discovered a generalised truncation function I implemented in About.jl 😆 (that would have been helpful while Ian and I repeated the work in our DMs on Slack)

function struncate(str::AbstractString, maxwidth::Int, joiner::AbstractString = "…", mode::Symbol = :center)
    textwidth(str) <= maxwidth && return str
    left, right = firstindex(str), lastindex(str)
    width = textwidth(joiner)
    while true
        if mode ∈ (:right, :center)
            (width += textwidth(str[left])) <= maxwidth || break
            left = nextind(str, left)
        end
        if mode ∈ (:left, :center) && width < maxwidth
            (width += textwidth(str[right])) <= maxwidth || break
            right = prevind(str, right)
        end
    end
    str[begin:prevind(str, left)] * joiner * str[nextind(str, right):end]
end

A single function like that seems tidier, but is it too atypical to put key functionality on a kwarg? Otherwise we might have had pad(.., mode = :right).

A single function like that seems tidier, but is it too atypical to put key functionality on a kwarg?

We could always use a single-function implementation internally (maybe with a Val argument?) but still expose ltrunc etc as the API.

Indeed. Just updated to the single internal implementation

Could the exported functions get more descriptive names? E.g., truncate_from_left. Or even truncate_string_from_left.

@nsajko these are supposed to be the counterparts to to rpad/lpad. I think the names make sense with that context?

IMO, given that using Base is the default for modules, the less names are exported from Base, cluttering non-bare modules, the better. Especially if the names are very short or not used especially often. Not sure how prevalent this opinion is, but there it is.

So, IMO, in order of preference:

1. descriptive public names
2. descriptive export-ed names or shorthand public names
3. shorthand export-ed names.

FWIW.

Ok. Fair.

truncate_right? Allows extending methods for non string types.

Not to open a can of worms, but it occurs to me that in cases like:

julia> struncate("🍕🍕🍕🍕🍕🍕xxxxxxxxxxx", 9, "…")
"🍕🍕🍕…xx"

The "centre" truncate call has 6 cells of 🍕 on the left, and 2 of x, which isn't very centred 😬.

(Sorry Ian 😅)

Just pushed a fix

julia> @time ctruncate("🍕🍕🍕🍕🍕🍕xxxxxxxxxxx", 9)
  0.000014 seconds (4 allocations: 112 bytes)
"🍕🍕…xxxx"